Heretofore, virtual machines (VM) have been known as a technique used by mainframes to run a plurality of operating systems on a single computer unit. According to the technique, a plurality of user tasks (processes and threads are generically called tasks hereunder) are executed while being switched on a plurality of virtual machines operating parallelly within the mainframe. A virtual machine is usually implemented as a process in the mainframe; a virtual machine may also be regarded as an operating system in view of its relationship to user tasks.
Generally, virtual machines are each assigned a predetermined time slice (allocated CPU time) in accordance with the priority of the virtual machine in question. Each virtual machine switches and runs user tasks within the assigned time slice. A technique for improving execution efficiency of such virtual machines is disclosed illustratively in JPA 5-197577, “Execution Priority Control System for Virtual Machines.”
The technique cited above involves a plurality of virtual machines and a virtual machine monitor for controlling the multiple virtual machines. On starting or ending the execution of a high priority task such as a system task, a virtual machine notifies the virtual machine monitor of the priority of the task in question. In response, the virtual machine monitor changes the execution priority of the virtual machine in question to comply with the received priority. Where the execution priority of each virtual machine is changed to match the priority of the task to be performed thereby, control over virtual machines is said to be executed efficiently.
Meanwhile, improvements in the performance of microcomputers, especially those for embedded uses, along with enhanced functionality of operating systems, have inspired a need in users to run and dynamically switch a plurality of operating systems concurrently on a single computer.
In such applications as mechanical controls at factories and plants and car navigation systems, among others, emphasis is placed on a real-time response capability of responding to changes in the external environment in real time, as well as on high reliability that ensures long-time uninterrupted operation. For these reasons, many such applications adopt a real-time operating system (real-time OS) that is highly responsive to external changes and is compact and module-based in structure. However, while stressing the real-time responsiveness and reliability, the real-time OS tends to be short on amenities of human-oriented interface.
By contrast, business-use operating systems (business-use OS) installed in common personal computers (PC) have user-friendly interface features that typically permit image-based user manipulations. For that reason, there has been a growing need for utilizing the business-use OS in applications dominated by real-time OS's. However, because it primarily addresses interactive exchanges with human operators, the business-use OS stresses throughput rather than interrupt responsiveness. That is, under the business-use OS, processing may continue with interruptions inhibited for a relatively long time. The business-use OS is not as compact as the real-time OS in terms of structure and consequently is less reliable. As such, the business-use OS is not fit for round-the-clock or other extended operations.
Still, if a business-use OS and a real-time OS are run and switched as needed on a single computer as in the case of multiple virtual machines (i.e., operating systems) run on a mainframe, it is possible to take advance of the benefits of both systems: user-friendly interface on the one hand, and real-time responsiveness and reliability on the other hand. Given today's enhanced performance of microcomputers, the scheme of running a plurality of operating systems on one computer unit is no longer an exclusive prerogative of mainframes.
If the relevance of each operating system is taken into consideration, the simplest scheme of switching multiple operating systems will involve having a real-time OS run most of the time and replaced by a business-use OS only when executable real-time OS tasks do not exist. However, there is no simple way of putting any one individual task above others in terms of priority (e.g., making real-time OS tasks always higher in priority than business-use OS tasks).
FIG. 27 shows an example demonstrating that simple classification of tasks in terms of priority is difficult to achieve. The figure illustrates a typical constitution of a simplified car navigation system assumed to be made up of four tasks: (1) a position recognition task 370 for recognizing the driving position of the car; (2) a route searching task 371 for finding the shortest route to a destination; (3) an interface task 372 for processing inputs from buttons and touch panel controls of the system; and (4) a game task 373 started during a rest stop. The position recognition task and the route searching task generally demand quick response and high reliability and are run by a real-time OS 111, while a business-use OS 110 with its user-friendly interface carries out the interface task and game task. But route search generally requires performing huge amounts of calculations, which may take as long as several seconds in a single pass. If tasks are simply classified as described above, then processing of the interface task is necessarily halted during the route search calculations and no key input effected repeatedly by the user will be recognized during that period.
The car navigation system shown in FIG. 27 has a high priority assigned to the interface task. When that task is placed in an executable state, the business-use OS needs to be run preferentially. According to the above-cited conventional technique (for “Execution Priority Control System for Virtual Machines”), however, it is assumed that all virtual machines (i.e., operating systems) have the same functionality. In order to address changes in the environment, most real-time OS's generally have a far larger number of priority levels than their business-use counterparts. Furthermore, the real-time and business-use OS's may have their priority levels arranged in a mutually opposite direction in an extreme case: the smaller the priority value (close to “0”), the higher the priority for the real-time OS; the larger the priority value, the higher the priority for the business-use OS. In that case, if each of the two operating systems requests a virtual machine monitor for priority over the other, the virtual machine monitor will have difficulty determining which operating system to start preferentially. The conventional technique above is thus incapable of controlling in a unified manner the business-use and real-time OS's each having conceptually different functions.